Domain-Driven Design: Bounded Contexts Beheersen voor Schaalbare Software

Domain-Driven Design (DDD) is een krachtige benadering voor het aanpakken van complexe softwareprojecten door te focussen op het kerndomein. De kern van DDD is het concept van Bounded Contexts. Het begrijpen en effectief toepassen van Bounded Contexts is cruciaal voor het bouwen van schaalbare, onderhoudbare en uiteindelijk succesvolle softwaresystemen. Deze uitgebreide gids duikt in de fijne kneepjes van Bounded Contexts en verkent zowel de strategische als de tactische patronen die ermee gemoeid zijn.

Wat is een Bounded Context?

Een Bounded Context is een semantische grens binnen een softwaresysteem die de toepasbaarheid van een specifiek domeinmodel definieert. Zie het als een duidelijk afgebakende reikwijdte waar specifieke termen en concepten een consistente en ondubbelzinnige betekenis hebben. Binnen een Bounded Context is de Ubiquitous Language, het gedeelde vocabulaire dat door ontwikkelaars en domeinexperts wordt gebruikt, goed gedefinieerd en consistent. Buiten deze grens kunnen dezelfde termen verschillende betekenissen hebben of helemaal niet relevant zijn.

In wezen erkent een Bounded Context dat een enkel, monolithisch domeinmodel vaak onpraktisch, zo niet onmogelijk, is om te creëren voor complexe systemen. In plaats daarvan pleit DDD voor het opbreken van het probleemgebied in kleinere, beter beheersbare contexten, elk met zijn eigen model en Ubiquitous Language. Deze decompositie helpt de complexiteit te beheersen, de samenwerking te verbeteren en flexibelere en onafhankelijke ontwikkeling mogelijk te maken.

Waarom Bounded Contexts gebruiken?

Het gebruik van Bounded Contexts biedt tal van voordelen bij softwareontwikkeling:

• Minder Complexiteit: Door een groot domein op te splitsen in kleinere, beter beheersbare contexten, vermindert u de algehele complexiteit van het systeem. Elke context kan gemakkelijker worden begrepen en onderhouden.
• Verbeterde Samenwerking: Bounded Contexts vergemakkelijken betere communicatie tussen ontwikkelaars en domeinexperts. De Ubiquitous Language zorgt ervoor dat iedereen binnen een specifieke context dezelfde taal spreekt.
• Onafhankelijke Ontwikkeling: Teams kunnen onafhankelijk aan verschillende Bounded Contexts werken zonder elkaar in de weg te zitten. Dit maakt snellere ontwikkelcycli en verhoogde flexibiliteit mogelijk.
• Flexibiliteit en Schaalbaarheid: Bounded Contexts stellen u in staat om verschillende delen van het systeem onafhankelijk te ontwikkelen. U kunt specifieke contexten schalen op basis van hun individuele behoeften.
• Verbeterde Codekwaliteit: Focussen op een specifiek domein binnen een Bounded Context leidt tot schonere, beter onderhoudbare code.
• Afstemming met het Bedrijf: Bounded Contexts sluiten vaak aan bij specifieke bedrijfscapaciteiten of -afdelingen, waardoor het gemakkelijker wordt om software af te stemmen op bedrijfsbehoeften.

Strategisch DDD: Bounded Contexts identificeren

Het identificeren van Bounded Contexts is een cruciaal onderdeel van de strategische ontwerpfase in DDD. Het omvat het begrijpen van het domein, het identificeren van belangrijke bedrijfscapaciteiten en het definiëren van de grenzen van elke context. Hier is een stapsgewijze aanpak:

1. Domeinverkenning: Begin met het grondig verkennen van het probleemgebied. Praat met domeinexperts, bekijk bestaande documentatie en begrijp de verschillende bedrijfsprocessen die erbij betrokken zijn.
2. Identificeer Bedrijfscapaciteiten: Identificeer de kernbedrijfscapaciteiten die het softwaresysteem moet ondersteunen. Deze capaciteiten vertegenwoordigen de essentiële functies die het bedrijf uitvoert.
3. Zoek naar Semantische Grenzen: Zoek naar gebieden waar de betekenis van termen verandert of waar verschillende bedrijfsregels van toepassing zijn. Deze grenzen duiden vaak op potentiële Bounded Contexts.
4. Overweeg Organisatiestructuur: De organisatiestructuur van het bedrijf kan vaak aanwijzingen geven over potentiële Bounded Contexts. Verschillende afdelingen of teams kunnen verantwoordelijk zijn voor verschillende gebieden van het domein. Conway's Wet, die stelt dat "organisaties die systemen ontwerpen, worden beperkt om ontwerpen te produceren die kopieën zijn van de communicatiestructuren van deze organisaties," is hier zeer relevant.
5. Teken een Context Map: Maak een Context Map om de verschillende Bounded Contexts en hun relaties te visualiseren. Deze kaart helpt u te begrijpen hoe de verschillende contexten met elkaar omgaan.

Voorbeeld: Een E-commerce Systeem

Overweeg een groot e-commerce systeem. Het kan verschillende Bounded Contexts bevatten, zoals:

• Productcatalogus: Verantwoordelijk voor het beheer van productinformatie, categorieën en attributen. De Ubiquitous Language omvat termen zoals "product", "categorie", "SKU" en "attribuut".
• Orderbeheer: Verantwoordelijk voor het verwerken van bestellingen, het beheren van zendingen en het afhandelen van retouren. De Ubiquitous Language omvat termen zoals "bestelling", "zending", "factuur" en "betaling".
• Klantenbeheer: Verantwoordelijk voor het beheer van klantaccounts, -profielen en -voorkeuren. De Ubiquitous Language omvat termen zoals "klant", "adres", "loyaliteitsprogramma" en "contactinformatie".
• Voorraadbeheer: Verantwoordelijk voor het bijhouden van voorraadniveaus en het beheren van opslaglocaties. De Ubiquitous Language omvat termen zoals "voorraadniveau", "locatie", "bestelpunt" en "leverancier".
• Betalingsverwerking: Verantwoordelijk voor het veilig verwerken van betalingen en het afhandelen van terugbetalingen. De Ubiquitous Language omvat termen zoals "transactie", "autorisatie", "afrekening" en "kaartgegevens".
• Aanbevelingsengine: Verantwoordelijk voor het geven van productaanbevelingen aan klanten op basis van hun browsegeschiedenis en aankoopgedrag. De Ubiquitous Language omvat termen zoals "aanbeveling", "algoritme", "gebruikersprofiel" en "productaffiniteit".

Elk van deze Bounded Contexts heeft zijn eigen model en Ubiquitous Language. Zo kan de term "product" verschillende betekenissen hebben in de Productcatalogus en de Orderbeheercontexten. In de Productcatalogus kan het verwijzen naar de gedetailleerde specificaties van een product, terwijl het in Orderbeheer simpelweg kan verwijzen naar het gekochte artikel.

Context Maps: Relaties tussen Bounded Contexts visualiseren

Een Context Map is een diagram dat de verschillende Bounded Contexts in een systeem en hun relaties visueel weergeeft. Het is een cruciaal hulpmiddel om te begrijpen hoe de verschillende contexten met elkaar omgaan en om weloverwogen beslissingen te nemen over integratiestrategieën. Een Context Map gaat niet in op de interne details van elke context, maar richt zich eerder op de interacties daartussen.

Context Maps gebruiken typisch verschillende notaties om de verschillende soorten relaties tussen Bounded Contexts weer te geven. Deze relaties worden vaak integratiepatronen genoemd.

Tactisch DDD: Integratiepatronen

Zodra u uw Bounded Contexts heeft geïdentificeerd en een Context Map heeft gemaakt, moet u beslissen hoe deze contexten met elkaar zullen interacteren. Hier komt de tactische ontwerpfase om de hoek kijken. Tactisch DDD richt zich op de specifieke integratiepatronen die u zult gebruiken om uw Bounded Contexts te verbinden.

Hier zijn enkele veelvoorkomende integratiepatronen:

• Gedeelde Kernel: Twee of meer Bounded Contexts delen een gemeenschappelijk model of code. Dit is een risicovol patroon, aangezien wijzigingen in de gedeelde kernel alle contexten kunnen beïnvloeden die ervan afhankelijk zijn. Gebruik dit patroon spaarzaam en alleen wanneer het gedeelde model stabiel en goed gedefinieerd is. Bijvoorbeeld, meerdere services binnen een financiële instelling kunnen een kernbibliotheek delen voor valutaberekeningen.
• Klant-Leverancier: Eén Bounded Context (de Klant) is afhankelijk van een andere Bounded Context (de Leverancier). De Klant vormt actief het model van de Leverancier om aan zijn behoeften te voldoen. Dit patroon is nuttig wanneer één context een sterke behoefte heeft om de andere te beïnvloeden. Een marketingcampagnebeheersysteem (Klant) kan de ontwikkeling van een klantdataplatform (Leverancier) sterk beïnvloeden.
• Conformist: Eén Bounded Context (de Conformist) gebruikt simpelweg het model van een andere Bounded Context (de Upstream). De Conformist heeft geen invloed op het model van de Upstream en moet zich aanpassen aan de wijzigingen ervan. Dit patroon wordt vaak gebruikt bij integratie met legacy-systemen of diensten van derden. Een kleine verkoopapplicatie kan simpelweg voldoen aan het datamodel dat wordt geleverd door een groot, gevestigd CRM-systeem.
• Anti-Corruptielaag (ACL): Een abstractielaag die tussen twee Bounded Contexts zit en vertaalt tussen hun modellen. Dit patroon beschermt de downstream context tegen wijzigingen in de upstream context. Dit is een cruciaal patroon bij het omgaan met legacy-systemen of diensten van derden die u niet kunt controleren. Bijvoorbeeld, bij integratie met een legacy salarissysteem kan een ACL het legacy dataformaat vertalen naar een formaat dat compatibel is met het HR-systeem.
• Gescheiden Wegen: Twee Bounded Contexts hebben geen relatie met elkaar. Ze zijn volledig onafhankelijk en kunnen onafhankelijk evolueren. Dit patroon is nuttig wanneer de twee contexten fundamenteel verschillend zijn en geen behoefte hebben om te interacteren. Een intern onkostenregistratiesysteem voor werknemers kan volledig gescheiden worden gehouden van het publiekelijk toegankelijke e-commerceplatform.
• Open Host Service (OHS): Eén Bounded Context publiceert een goed gedefinieerde API die andere contexten kunnen gebruiken om toegang te krijgen tot de functionaliteit ervan. Dit patroon bevordert losse koppeling en maakt flexibelere integratie mogelijk. De API moet worden ontworpen met de behoeften van de consumenten in gedachten. Een betalingsgateway-service (OHS) exposeert een gestandaardiseerde API die verschillende e-commerceplatforms kunnen gebruiken om betalingen te verwerken.
• Gepubliceerde Taal: De Open Host Service gebruikt een goed gedefinieerde en gedocumenteerde taal (bijv. XML, JSON) om met andere contexten te communiceren. Dit zorgt voor interoperabiliteit en vermindert het risico op verkeerde interpretatie. Dit patroon wordt vaak gebruikt in combinatie met het Open Host Service patroon. Een supply chain management systeem exposeert data via een REST API met behulp van JSON Schema om een duidelijke en consistente data-uitwisseling te garanderen.

Het Juiste Integratiepatroon Kiezen

De keuze van het integratiepatroon hangt af van verschillende factoren, waaronder de relatie tussen de Bounded Contexts, de stabiliteit van hun modellen en de mate van controle die u over elke context heeft. Het is belangrijk om de afwegingen van elk patroon zorgvuldig te overwegen voordat u een beslissing neemt.

Veelvoorkomende Valkuilen en Anti-Patronen

Hoewel Bounded Contexts ongelooflijk nuttig kunnen zijn, zijn er ook enkele veelvoorkomende valkuilen die vermeden moeten worden:

• Big Ball of Mud: Het niet correct definiëren van Bounded Contexts en eindigen met een monolithisch systeem dat moeilijk te begrijpen en te onderhouden is. Dit is het tegenovergestelde van wat DDD wil bereiken.
• Accidentele Complexiteit: Onnodige complexiteit introduceren door te veel Bounded Contexts te creëren of door ongeschikte integratiepatronen te kiezen.
• Voortijdige Optimalisatie: Proberen het systeem te vroeg in het proces te optimaliseren voordat het domein en de relaties tussen de Bounded Contexts volledig zijn begrepen.
• Conway's Wet Negeeren: Het niet afstemmen van de Bounded Contexts op de organisatiestructuur van het bedrijf, wat leidt tot communicatie- en coördinatieproblemen.
• Overmatige Afhankelijkheid van Gedeelde Kernel: Het te vaak gebruiken van het Shared Kernel patroon, wat leidt tot strakke koppeling en verminderde flexibiliteit.

Bounded Contexts en Microservices

Bounded Contexts worden vaak gebruikt als startpunt voor het ontwerpen van microservices. Elke Bounded Context kan worden geïmplementeerd als een afzonderlijke microservice, wat onafhankelijke ontwikkeling, deployment en schaalvergroting mogelijk maakt. Het is echter belangrijk op te merken dat een Bounded Context niet noodzakelijkerwijs als microservice hoeft te worden geïmplementeerd. Het kan ook worden geïmplementeerd als een module binnen een grotere applicatie.

Bij het gebruik van Bounded Contexts met microservices is het belangrijk om de communicatie tussen de services zorgvuldig te overwegen. Veelvoorkomende communicatiepatronen zijn REST API's, message queues en event-driven architecturen.

Praktische Voorbeelden van Over de Hele Wereld

De toepassing van Bounded Contexts is universeel toepasbaar, maar de specifieke invulling zal variëren afhankelijk van de branche en context.

• Wereldwijde Logistiek: Een multinationaal logistiek bedrijf zou afzonderlijke Bounded Contexts kunnen hebben voor *Zendingtracking* (afhandelen van real-time locatie-updates), *Douaneafhandeling* (omgaan met internationale regelgeving en documentatie), en *Magazijnbeheer* (optimaliseren van opslag en inventaris). Het "artikel" dat wordt gevolgd, heeft in elke context heel verschillende representaties.
• Internationaal Bankieren: Een wereldwijde bank zou Bounded Contexts kunnen gebruiken voor *Particulier Bankieren* (beheer van individuele klantrekeningen), *Zakelijk Bankieren* (afhandeling van bedrijfsleningen en transacties), en *Beleggingsbankieren* (omgaan met effecten en handel). De definitie van "klant" en "rekening" zou aanzienlijk verschillen in deze gebieden, wat diverse regelgeving en bedrijfsbehoeften weerspiegelt.
• Meertalig Contentbeheer: Een wereldwijde nieuwsorganisatie zou afzonderlijke Bounded Contexts kunnen hebben voor *Contentcreatie* (auteurswerk en bewerken van artikelen), *Vertaalbeheer* (afhandelen van lokalisatie voor verschillende talen), en *Publicatie* (distribueren van content via verschillende kanalen). Het concept van "artikel" heeft verschillende attributen, afhankelijk van of het wordt geschreven, vertaald of gepubliceerd.

Conclusie

Bounded Contexts zijn een fundamenteel concept in Domain-Driven Design. Door Bounded Contexts effectief te begrijpen en toe te passen, kunt u complexe, schaalbare en onderhoudbare softwaresystemen bouwen die zijn afgestemd op bedrijfsbehoeften. Denk eraan om de relaties tussen uw Bounded Contexts zorgvuldig te overwegen en de juiste integratiepatronen te kiezen. Vermijd veelvoorkomende valkuilen en anti-patronen, en u bent goed op weg om Domain-Driven Design onder de knie te krijgen.

Bruikbare Inzichten

1. Begin Klein: Probeer niet al uw Bounded Contexts tegelijk te definiëren. Begin met de belangrijkste gebieden van het domein en herhaal naarmate u meer leert.
2. Werk Samen met Domeinexperts: Betrek domeinexperts gedurende het hele proces om ervoor te zorgen dat uw Bounded Contexts het bedrijfsdomein nauwkeurig weerspiegelen.
3. Visualiseer Uw Context Map: Gebruik een Context Map om de relaties tussen uw Bounded Contexts te communiceren naar het ontwikkelingsteam en de belanghebbenden.
4. Continu Herstructureren: Wees niet bang om uw Bounded Contexts te herstructureren naarmate uw begrip van het domein evolueert.
5. Omarm Verandering: Bounded Contexts zijn niet in steen gehouwen. Ze moeten zich aanpassen aan veranderende bedrijfsbehoeften en technologische vooruitgang.